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(54) Method tor Implementing a non-volatile caching product tor networks and cd-roms 



(57) A network and CD-ROM caching product that 
runs under both Windows 3.X and Windows 95, is com- 
pletely transparent to end-users, and works with a wide 
variety of file systems running under both Windows 3 *X 
and Windows 95 is disclosed. The approach used to ful- 
fill these requirements has been to utilise the services 
provided by a virtual device driver (VxD) supplied with 
Windows 95 known as the Installable File System Man- 
ager (IFSMGR). Windows 95 is designed so that all fie 
system input/output (I/O) requests may be "hooked" to 



the IFSMGR VxD. The disclosed caching product is 
effectively "layered" between the IFSMGR VxD and the 
generic file system of Windows 95. The disclosed cach- 
ing product has been designed so that it will run under 
both operating systems. This has been accomplished 
by rewriting portions of the Windows 95 IFSMGR VxD, 
enabling it to run under Windows 3.X. The rewritten ver- 
sion is based on the IFSMGR specification provided by 
Microsoft Corporation. 
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Description 

piPinpFTHE INVENTION: 

This invention relates to non-volatile caching sys- 
tems for data processing systems, and methods tor 
implementing such systems. 

DESCRIPTION OF RELATED ART: 

Caching has tong been employed to increase per- 
formance of a relatively slow computer memory 
resource when a faster memory resource, which typi- 
cally has a higher cost per stored bit is available. Typi- 
cally, a temporary memory block within the taster 
memory resource fi e., a cache) is established for stor- 
ing only a portion of the information stored within the 
slower memory resource. Rather than store within the 
faster memory resource an entire application program 
or an entire data fie that may be resident on the slower 
memory resource, certain algorithms are employed to 
determine which portions of the program or data file are 
most likely to be accessed. When the system's central 
processing unit (CPU) caBs a memory location that i6 
not stored in the cache, the cache (if completely fffled) 
must be at least partially overwriten with the required 
data from the slower memory resource. Likewise, when 
permanent changes are made to data, data in both the 
cache and the slower memory resource must be 
updated to reflect that change. 

As this is written there are roughly 1 50 million com- 
puters throughout the world capable of performing gen- 
eral business-related tasks. When the rapid proliferation 
of personal computers began in the early 1980s, nearly 
all of them were employed as stand-alone unite. Hew- 
ever, multi-user systems were soon developed. These 
early multi-user systems ran software written for the 
CP/M disk operating system, which had been written by 
Gary Kildall and was marketed by his company Digital 
Research, Inc. The mufti-user disk operating system 
MP/M suppled by Digital Research, inc. connected sev- 
eral "dumb" terminals to a single microprocessor and a 
shared disk drive, while TurboD03--a much more 
sophisticated product supplied by an unrelated com- 
pany-utilized a master/slave arrangement much like the 
Local Area Networks (LANs) in use today. 

Both the MP/M and the TurboDOS disk operating 
systems ran on computer systems based on either the 
Intel 8080 microprocessor or the Zitog Z-80 microproc- 
essor. Neither of these early microprocessors could 
directly address more than 65,536 bytes of random- 
access memory. As a consequence of MP/M and Turbo- 
DOS requiring a minimum of about 50,000 bytes of ran- 
dom access memory only about 15,000 bytes of 
addressable memory remained tor application pro- 
grams. As few application programs, other than simple 
word processors, required 15,000 bytes or less, the 
early mufti -user systems were, for the most part more 
intellectual curiosities than they were practical, general- 



use, mutti-user data processing systems. 

Distributed data processing (i.a, multiple LANs 
interconnected via a long-distance data link) using 
either MP/M or TurboDOS was even more hopeless, as 

£ it would have required loading a communication pro- 
gram into memory, in addition to the operating system, 
before application software could be loaded. However, 
with the introduction of IBM-compatible computers 
based on the Intel 80286 microprocessor, which was 

10 designed to address set/era) megabytes of random- 
access memory, the development of practical LANs and 
distributed data processing systems became feasible. 
Although Novell Corporation initially captured a majority 
share of the LAN market, the number of networks utOiz- 

is ing LAN software from Microsoft Corp. has been grow- 
ing. 

Present-day LANs generally use a twisted wire pair 
or a coaxial cable to interconnect incBvidual user com- 
puter systems to a server system. The interconnection 

20 of LANs is accomplished via telephone lines, special 
dedicated data Ones, microwave, or satellite links. 
Acoustic links can be made using electrically-conduc- 
tive or fiber-optic cables. For acoustic links, each end of 
the link generally requires a modem. The other links typ- 

26 icalty utffize a "bridge'' and a "router" at each end. 

Distributed data processing networks and the LANs 
within those distributed networks can often benefit from 
caching. Typically, links between LANs of a distributed 
processing network are slower than the interoonnec- 

so tions between the nodes (i.e., individual computers) of a 
LAN. Furthermore, though a distant memory resource 
(ag. a disk drive on a distant server system) may be as 
fast or even testa' than local memory resources, long 
distance interconnections over a data link can dramati- 
cs cally slow access time to that distant resource. Regard- 
less of the type of link between the LANs of a distributed 
processing network, or between the nodes (i.e., individ- 
ual systems) of a LAN, each data link has a given band- 
width which will permit only a finite amount of data to be 

40 simultaneously transferred over the link. Once the band- 
width is exceeded, as for example when more than a 
certain number of users are attempting to communicate 
over the same link (whether between LANs or within a 
LAN), response time over that link typicaly degrades as 

45 each user's request is delayed in order to evenly accom- 
modate all competing requests. Consequently, caching 
of data read over a n etwork can generally increase sys- 
tem performance both by reducing data fink loading and 
by providing the end user with a cache of rapidly acces- 

so stile data. 

Within the last several years, compact disc read- 
only-memory devices (CD-ROMs) have become 
extremely popular due to the availability of low-cost 
high-capacity compact disk storage media and reJa- 

55 livery low cost CD-ROM readers (drives). In fact nearly 
all new personal computers being sold in the U.S. 
include an installed CD-ROM drive. Although current 
CD-ROM madia are capable of storing approximately 
450-500 megabytes of data, access to that data is con- 
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siderably slower than data stored on a modern hard disk 
drive. For example, the current standard for a high-per- 
formance CD-ROM drive, known as a "6X* drive is 
capable of reading, at most, about 600 kilobytes of data 
per second. A modern high-speed IDE hard disk drive, 
on the other hand, is capable of reading about six meg- 
abytes per second-roughly ten times the speed of a 6X 
CD-ROM drive. Thus, CD-ROM drive performance may 
also be greatly enhanced through caching. 

Many graphical user interface (GUI) environments, 
such as Microsoft® Windows™ version 3 JC, Microsoft 
Windows 95. Windows NT®, IBM Corporation's 08/2®. 
and Geoworks® have been developed over the years. 
Of the aforementioned products, only Windows NT and 
OS/2 are true operating systems, as Geoworks and 
Windows 3.x must be loaded and run under the venera- 
ble Microsoft MS-DOS operating system. Windows 95 is 
somewhat of a hybrid, as it also requires portions of MS- 
DOS for its operation. For the sake of simplicity, though, 
both Windows 3.X and Windows 95 are referred to here- 
inafter as operating systems. 

As this is written, Microsoft Windows ver. 3.X is far 
and away the most used operating system, having been 
bundled with nearly every personal computer sold 
between 1989 and mid-1995. However, from the date of 
its release in 1995, the Microsoft Windows 95 operating 
system from Microsoft Corporation has been bundled 
with most new, high-performance personal computers. 
In less than a year, it has become the operating system 
of choice for most business applications, and is 
expected to rapidly supplant Windows 3.X as the most 
used operating system for personal computers. The 
potential exists tor signrficantty increasing the perform- 
ance of both CD-ROM drives and distributed processing 
networks operating under Windows 3.X and Windows 
95 operating systems through caching. 

SUMMARY OF THE INVENTION 

Shortly after the release of Windows 95, Sun Micro- 
systems, Inc. (hereinafter also "Sun") set about to cre- 
ate a network and CD-ROM caching product that runs 
under both Windows 3.X and Windows 95, is com- 
pletely transparent to end-users, and works with a wide 
variety of file systems running under both Windows 3.X 
and Windows 95. The approach used to fulfill these 
requirements has been to utiBze the services provided 
by a software program module within Windows 95 
known as the Installable File System Manager (IFS- 
MGR). Microsoft Windows 3.x and Windows 95 operat- 
ing system platforms include 32-bit components, each 
of which runs at Ring-0 and which is called a Virtual 
Device Driver or VxD. for short The IFSMGR program 
module is such a virtual device driver. Windows 95 is 
designed so that all file system input/output (I/O) 
requests are "hooked" to the IFSMGR VxD. 

The caching product developed by Sun Microsys- 
tems, Inc. is called "Solstice PC-CacheFS" (hereinafter 
"PG-Cache-FS"). The PC-CacheFS caching product. 



which also tits the definition of a virtual device driver, is 
effectively layered" between the IFSMGR VxD and the 
generic file system of Windows 95. 

Rather than create separate caching products for 

5 Windows 3.X and Windows 95, the PC-CacheFS cach- 
ing product has been designed so that it will run under 
both operating systems. However, the Windows 3.X 
operating system has no IFSMGR virtual device driver. 
Thus, portions of the Windows 95 IFSMGR VxD have 

10 been rewritten to run under Windows 3.X. The rewrite is 
based on the IFSMQR specification provided by Micro- 
soft Corporation. Thus, neither the PC-CacheFS cach- 
ing product (VxD) nor the Windows operating systems, 
themselves, need be rewritten for the sake of compati- 

16 bility. 

Brjef Description of Drawings 



Fig. 1 illustrates a computing system for performing 
20 the computer implemented steps of the method in 
accordance with the invention; and 
Fig. 2 Is a flow chart depicting the logical operation 
of the caching virtual device driver. 

26 Detailed Desk top, ftf P™terrad Embodiments 

The ernbodiments of the invention described herein 
may be implemented as logical operations in a distrib- 
uted processing system having client and server corn- 
so puling systems. The logical operations of the present 
invention are implemented (1 ) as a sequence of compu- 
ter implemented steps running on the computing sys- 
tem and (2) as interconnected machine modules within 
the computing system. The implementation is a matter 
as of choice that is dependent on the performance require- 
ments of the computing system implementing the inven- 
tion. Accordingly, the logical operations making up the 
erntxxfiments of the invention described herein are 
referred to variously as operations, steps or modules. 
do The operating environrnent in which the present 
invention is used encompasses the general distributed 
computing system, wherein genera) purpose comput- 
ers, workstations, or personal computers (hereinafter 
local nodes) are connected via communication links of 
46 various types, in a client-server arrangement, wherein 
programs and data, many in the form of objects, are 
made available by various members of the system. 
Some of the elements of a general purpose workstation 
computer are shown in Figure 1 , wherein a processor 1 
so is shown, the processor having an input/output (I/O) 
section, a central processing unit (CPU) 3 and a mem- 
ory section 4. The I/O section 2 is connected to a key- 
board 5, a display unit 6, a disk storage unit 9 and a CD- 
ROM drive unit 7. The CD-ROM unit 7 can read a CD- 
55 ROM medium 8 which typically contains programs 10 
and data. The computer program products containing 
mechanisms to effectuate the apparatus and methods 
of the present invention may reside in the memory sec- 
tion 4, or on a disk storage unit 9. or on the CD-ROM 8 
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of such a system. Examples of such systems include 
SPARC systems offered by Sun MicroSystems, Inc.. 
personal computers offered by IBM Corporation and by 
other manufacturers of IBM-compatible personal com- 
puters, and systems running the UNIX operating sys- s 
tern. 

The preferred embodiment of the present invention 
provides caching for information stored on local CD- 
ROM drives and lor information stored at non-local net- 
work resources, which may include both local and dis- 
tant server system disk drives and the like. Such 
caching functions are provided in a single caching prod- 
uct which may be loaded under either Windows 3.X or 
Windows 95. Tne caching product functions such that it 
is completely transparent to end-users, and works with 
a wide variety of file systems running under both Win- 
dows 3.X and Windows 95. 

The heretofore enumerated functions of the pre- 
ferred ernbodi merit are provided in the form of what 
Microsoft Corporation calls a virtual device driver, or 
VxD for short. This caching VxD interfaces with another 
virtual device driver called the Installable File System 
Manager (IFSMGR, for short] that is supplied with Win- 
dows 95. Windows 95 is designed so that all file system 
input/output (I/O) requests are "hooked 1 ' to the IFSMGR 
VxD. In a preferred embodiment of the invention, the 
-caching VxD is layered between the IFSMGR VxD and 
the generic file system of Windows 95. In a preferred 
embodiment of the invention, the caching product 
receives all file system I/O requests from the IFSMGR 
VxD and implements a caching scheme in accordance 
with set-up instructions which have been pre-pro- 
grammed by the user of a local node. In other words, the 
user tells the caching product which network or CD- 
ROM drives) are to be cached. — - - 

Rather than create separate caching products for 
Windows 3X and Windows 95. the PC-CacheFS cach- 
ing product has been designed so that it will run under 
both operating systems. However, as the Windows 3.X 
operating system has neither an IFSMGR virtual device 
driver nor a functional equivalent, a special IFSMGR vir- 
tual device driver has been incorporated in the caching 
VxD. Thus, when the preferred embodiment of the cach- 
ing product is loaded under Windows 3.X, this special 
IFSMGR VxD is called whenever a system 170 request 
is issued by the system CPU. The special IFSMGR VxD, 
which is largely based on the Windows 95 IFSMGR 
specification provided by Microsoft Corporation, 
includes modifications which permit it to operate under 
Windows 3.X. By using this approach, neither the cach- 
ing VxD nor the Windows operating systems, them- 
selves, need be rewritten for the sake of corrpatibflity. 

The interface of the caching VxD with the IFSMGR 
VxD is Implemented by the following exemplary, 
pseudo-code routine; 

1 . Is this Windows boot-time initialization? 

Yes: Goto Step 2. 



No: Goto Step 3. 

2. "Hook" the IFSMGR service by calling the 
IFSMgr.lnstallFileSystemApiHook routine, specify- 
ing CacheHook as the callback name for the Hook 
to the caching product. 

3. The IFSMGR calls CacheHook with a file I/O 
request. 

— 4. Does this request involve a network drive or CD- 
ROM drive that has been configured for caching? 

Yes: Goto Step 6. 

No: Go to Step 5, as the request is of no fur- 
ther interest. 

5. Control returned to IFSMGR VxD and the file I/O 
request is chained to the next IFSMGR hook, or to 
the IFSMGR itself. 

- 6. Does the local hard disk cache have valid data in 
it to satisfy this request? 

Yes: Goto Step 9. 
No: Goto Step 7. 

7. Can down to the network or CD-ROM file system 
and retrieve at least enough data to satisfy the 

-- request, retaining control from the IFSMGR. 

8. Cache the retrieved data by saving it either in 
random-access memory or on the local hard disk 
for subsequent retrieval. 

9. Provide data from the cache which resolves the 
I/O request, and go to Step 5. 

In order to further clarify the operational flow of the 
caching VxD, the foregoing pseudo-code routine has 
been formatted in the flow chart of Figure 2. 

Any virtual device driver may monitor ail system file 
I/O requests by establishing a hook to the IFSMGR VxD. 
This is accomplished by calling a routine within the FS- 
MGR VxD called IFSMgrJrwtalRleSysternAp^ 
and providing it with a unique callback name, tn this 
case, the name "CacheHook" has been arbitrarily cho- 
sen as the callback name for the caching VxD. 

The IFSMGR VxD retains a table of all hook 
requests made by various virtual device drivers. For 
example, in addition to the caching VxD, a virus scan- 
ning VxD may also have a hook to the IFSMGR VxD. 
Such a virus scanning VxD may be responsible for 
scanning all executable files for viruses as they are 
being read Ail IFSMGR hooks are chained together. In 
order to initiate the chaining sequence, the IFSMGR 
VxD passes an incorrting file I/O request to the first hook 
along with information which sequentially identifies all 
other requesting hooks. Each hook analyzes the Incom- 
ing f ile I/O request and decides, on the basis of thB type 
of request whether or not to take action. When each 
hook finishes with the incoming file I/O request, it 
passes ("chains") the request to the next hook in the 
sequence. The final hook in the sequence returns con- 



75 



so 



25 



30 



35 



40 



46 



SO 



7 



EP 0 805 397 A2 



8 



troi of the file I/O request to the IFSMGR VxD. 

The cache may be established in either the local 
systems random access memory or on the local hard- 
disk drive. Alternatively, a two-tier caching system may 
be implemented such thai a large block of non-volatile s 
cached data resides on the local hard-disk drive, while a 
smaller block of volatile cached data resides within a 
portion of the random access memory. Such caching 
schemes are already well known in the art and will not 
be discusses herein in greater detail. 10 

While the invention has been particularly shown 
and described with reference to a preferred embodi- 
ment thereof, it will be understood by those skilled in the 
art that various other changes in the form and details 
may be made therein without departing from the spirit is 
and scope of the invention. 

Claims 

1. A method encoded in the form of binary program 20 
instructions for implementing a cachbig virtual 
device driver responsive to file I/O requests within a 
Microsoft Windows operating system, said operat- 
ing system being provided with a virtual device 
driver (VxD) identified as the Installable File System 25 
Manager (IFSMGR), said method implemented on 

a local node computer system eta networked data 

processing system having at least one server com- 
puter system, said local node having a central 
processing unit (CPU) (3), random access memory, so 
a local data bus. and at least one local mass stor- 
age device on which data can be alterably stored, 
said server system having at least one mass stor- 
age device on which data can be after ably stored, 
~ said method comprising the steps of : 

providing (1 10) for establishing a hook (120) to 
the IFSMGR VxD at boot time initialisation of 
the Windows operating system; 
providing (110) tor receiving a call (130) from 40 
the IFSMGR VxD whenever the focal node sys- 
tem processes a file I/O request: 
providing for assuming control of the request 
determining (140) whether or not each request 
involves data on a mass storage device that 45 
has been configured by the user tor caching; 
providing for returning control (150) of the 
request to the IFSMGR VxD if a request does 
not involve data on a mass storage device that 
has not been configured for caching; so 
if a request does involve data on a mass stor- 
age device that has been configured for cach- 
ing, then providing for determining (160) 
whether or not data which satisfies the request 
resides within an established cache at the focal 55 
node; 

if data which satisfies the request resides 
within the established cache, then providing 
(190) for supplying that data to the local data 



bus, and returning control (150) of the request 
to the IFSMGR VxD; and 
if no data which satisfies the request resides 
within the established cache* then providing for 
retrieving (170) a block of data, which includes 
the data which satisfies the request from the 
server system's mass-storage device, storing 
(180) the retrieved block in the cache, and sup- 
— plying (190) the data which satisfies the 
request to the local data bus, and returning 
control (150) of the request to the IFSMGR 
VxD. 

2. A method implementing a caching virtual device 
driver responsive to file I/O requests within a win- 
dows based operating system, said operating sys- 
tem being provided with a virtual device driver 
(VxD) identified as an Installable File System Man- 
ager (IFSMGR), said method implemented on a 
data processing system having a random access 
memory, a data bus, and a first mass storage 
device on which data can be alterably stored, said 
data processing system being coupled to at least a 
second mass storage device from which data is to 
be cached, said method comprising the steps of: 

providing for establishing a hook (120) to the 
IFSMGR VxD at boot time initialisation of the 
Windows operating system; 
providing for receiving (130) a call from the IFS- 
MGR VxD whenever the system processes a 
file I/O request 

providing (140) tor assuming control of the 
request and determining whether or not each 
request involves data on the second mass stor- 
age device; 

providing for returning control (150) of the 
request to the IFSMGR VxD if a request does 
not involve data on the second mass storage 
device; 

if a request does involve data on the second 
mass storage device, then providing for deter- 
mining (160) whether or not data which satis- 
fies the request resides within a cache 
established on the data processing system; 
if data which satisfies the request resides 
within the established cache, then providing 
(190) tor supplying that data to the data bus, 
and returning (1 50) control of the request to the 
IFSMGR VxD; and 

if no data which satisfies the request resides 
within the established cache, then providing for 
retrieving (170) a block of data which includes 
the data which satisfies the request from the 
second mass-storage device, storing (180) the 
retrieved block in the established cache, and 
supplying (190) the data which satisfies the 
request to the data bus. end returning control 
(150) of the request to the IFSMGR VxD. 
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3. The method of Claim 2, wherein the second mass- 
storage device is a CD-ROM drive (7). 

4. The method of Claim 2, wherein the second mass- 
storage device is located on a server computer sys- s 
tern to which the data processing system Is coupled 
via a network link. 

5. The method of Claim 2, wherein said cache is 
established within the random access memory. " 

6. The method of Claim 2. wherein said cache is 
established on the first mass-storage device. 

7. The method of Claim 2, wherein said cache is is 
established in both the random access memory and 

on the first mass-storage device. 

8. A computer program storage medium encoding a 
program of instructions tor a process for implement- so 
ing a caching system responsive to file I/O requests 
within a Microsoft Windows operating system, said 
operating system being provided with a virtual 
device driver (VxD) identified as the Installable FBe 
System Manager (IFSMQR), said process imple- 2S 
merited on a data processing system having a ran- 

_ dom access memory, a data bus, and a first mass 
storage device on which data can be alterably 
stored, said data processing system being coupled 
to at least a second mass storage device from 30 
which data is to be cached, said instructions being 
readable and executable by a computer system, 
said process comprising the steps of. 

providing (110) for establishing (120) a hookto 35 
the IFSMQR VxD at boot time initialisation of 
the Windows operating system; 
providing (110) for receiving (130) a call from 
the IFSMGR VxD whenever the system proc- 
esses a file I/O request; 
providing (140} tor assuming control of the 
request and determining whether or not each 
request involves data on the second mass stor- 
age device; 

providing for returning (150) control of the 46 
request to the IFSMGR VxD if a request does 
not involve data on the second mass storage 
device; 

if a request does involve data on the second 
mass storage device, then providing tor deter- so 
mining (160) whether or not data which satis- 
fies the request resides within a cache 
established on the data processing system; 
if data which satisfies the request resides 
within the established cache, then providing tor ss 
supplying (190) that data to the data bus, and 
returning (150) control of the request to the 
IFSMGR VxD; and 

H no data which satisfies the request resides 



within the established cache, then providing for 
retrieving (170) a block of data, which includes 
the data which satisfies the request, from the 
second mass-storage device, storing (180) the 
retrieved block in the established cache, and 
supplying (190) the data which satisfies the 
request to the data bus, and returning (150) 
control of the request to the IFSMGR VxD. 

9. The method of Claim 8, wherein the second mass- 
storage device is a CD-ROM drive (7). 

10. The method of Claim 8. wherein the second mass- 
storage device is located on a server computer sys- 
tem to which the data processing system is coupled 
via a network link. 

11. "The method of Claim 8, wherein said cache is 
established within the random access memory. 

12. The method of Claim 8. wherein said cache is 
established on the first mass-storage device. 

13. A computer implemented process for implementing 
a caching system responsive to ffle I/O requests 
within a windows-based operating system, said 
operating system being provided with a virtual 
device driver (VxD) identified as an Installable File 
System Manager (IFSMGR), said process imple- 
mented oh a data processing system having a ran- 
dom access memory a data bus, and a f irst mass 
storage device on which data can be alterably 
stored, said data processing system being coupled 
to at least a second mass storage device from 

- which data is to be cached, said process compris- 
ing the steps of: 

providing for establishing (120) a hook to the 
IFSMGR VxD at boot time initialisation of the 
Windows operating system; 
providing for receiving (1 80) a call from the IFS- 
MGR VxD whenever the system processes a 
file I/O request 

providing (140) for assuming control of the 
request and determining whether or not each 
request involves data on the second mass stor- 
age device; 

if a request does involve data on the second 
mass storage device, then providing for deter- 
mining (160) whether or not data which satis- 
fies the request resides within a cache 
estabfished on the data processing system; 
if data which satisfies the request resides 
within the established cache, then providing for 
supplying (190) that data to the data bus, and 
returning (150) control of the request to the 
IFSMGR VxD; and 

if no data which satisfies the request resides 
within the established cache, then provkf ng for 



6 



11 



EP 0 805 397 A2 



12 



retrieving (170) a block of data, which includes 
the date which satisfies the request, from the 
second mass-storage device, storing the 
retrieved block in the established cache, and 
supplying the data which satisfies the request 
to the data bus, and returning control of the 
request to the IFSMQR VxD. 

1 4. The method of Claim 1 3, wherein the second mass- 
storage device is a CD-ROM drive (7). 

15. The method of Claim 13. wherein the second mass- 
storage device ts located on a server computer sys- 
tem to which the data processing system is coupled 
via a network link. 

16. The method of Claim 13, wherein said cache is 
established within the random access memory. 

17. A method for providing a caching driver routine, 
said caching driver routine being interposed 
between a file handling system and a file system 
manager routine, said fie handling system and said 
file system manager being components of an Derat- 
ing system running on a local node, said file system 
manager routine providing other driver routines 

-temporary access to and control of ffle system 
input/output (I/O) requests on demand, said 
method comprising the steps of: 

providing for demanding from the file system 
manager routine temporary access to end con- 
trol of file system input/output requests; 
providing lor receiving a call from the file sys- 
— ™tem manager routine whenever the local node 
system processes a file I/O request; 
providing (140) for the caching driver routine to 
assume control of the request if the request 
involves data on a mass storage device that is 
to be stored in a cache memory; 
providing (160) for supplying (190) the 
requested data to the local node from the 
cache memory if the requested data is resident 
in the cache memory, or alternatively, providing 
tor supplying (1 70) the requested data to the 
local node from the mass storage device and 
writing (180) a block of data from the mass 
storage device, which includes the requested 
data, into the cache memory; 
providing for returning control of the I/O request 
to the file system manager. 

18. The method of Claim 17, wherein said operating 
system Is a Microsoft Windows operating system. 

19. The method of Claim 18, wherein said file system 
manager is an Installable File System Manager 
(IFSMQR) virtual device driver. 
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20. The method of claim 19, wherein the step of provid- 
ing for demanding from the file system manager 
routine temporary access to and control of file sys- 
tem irtpuVoutput requests is accomplished by 
establishing (120) a hook to the IFSMGR virtual 
device driver. 

21. The method of Claim 20, wherein establishment 
(120) of the hook to the IFSMQR virtual device 
driver is accomplished at boot-time initialisation of 
the Windows operating system. 

22. A method for providing a virtual device driver for 
data requests on a computer at a local node of a 
computer network having a server that includes a 
mass storage device, comprising the steps of: 

rf a request involves data on a mass storage 
device that has not been configured tor cach- 
20 ing, allowing a virtual device driver to control 

the request; and 

if the request Involves data on a mass storage 
device that has been configured for caching, 
and if the request involves data within the 

25 cache at the local node, then supplying the 

data to a local bus, and if the request involves 
data not within the cache at the local node, 
then retrieving at least some of data from the 
mass-storage device of the server, storing the 

30 retrieved data in the cache at the local node, 

and supplying the data to the local bus. 

23. The method of claim 22 wherein said method is 
encoded in the form of program instructions, 
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24. The method of claim 23 wherein said program 
instructions are binary program instructions. 

25. The method of claim 22 wherein said computer 
operating system is a Microsoft Windows operating 
system. 

26. The method of claim 25 wherein said virtual device 
driver is an Installable File System Manager (IFS- 
MGR) within said Microsoft Windows operating sys- 
tem. 



27. The method of claim 22 further comprising estab- 
lishing a hook to the virtual device driver to enable 
so said virtual device driver to assume control after a 
data operation. 

2a The method of claim 27 wherein said step of estab- 
lishing a hook to the virtual device driver comprises 
ss establishing a hook to the virtual device driver at 
boot time initialisation of the operating system 

29. A method for implementing a caching virtual device 
driver responsive to I/O requests within a windows 
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based operating system which is provided with a 
virtual device driver (VxD), said method imple- 
mented on a local node computer system of a net- 
worked computer system having a server 
computer, said local node having a central process- $ 
ing unit (CPU), random access memory, a local 
data bus, and at least one local mass storage 
device on which data can be alterably stored, said 
server system having at least one mass storage 
device on which data can be alterably stored, com- 10 
prising the steps of: 

establishing (120) a hook to the VxD at boot 
time initialisation of the operating system; 
receiving (130) a call from the VxD whenever 75 
the local node system processes a I/O request; 
assuming control of the request determining 
(140) whether or not each request involves 
data on a mass storage device that has been 
configured by the user tor caching; so 
returning (150) control of the request to the 
VxD if a request does not involve data on a 
mass storage device that has not been config- 
ured for caching; 

if a request does involve data on a mass stor- 26 
age device that has been configured for cach- 
ing, then determining (160) whether or not data 
which satisfies the request resides within an 
established cache at the local node; 
rf data which satisfies the request resides so 
within the estabfished cache, then supplying 
(190) that data to the local data bus, and 
returning (150) control of the request to the 
VxD; and 

if no data which satisfies the request resides « 
within the established cache, then retrieving 
(170) a block of data, which includes the data 
which satisf ies the request, from the mass-stor- 
age device of the server system, storing (180) 
the retrieved block in the cache, and supplying 40 
(1 70} the data which satisfies the request to the 
local data bus, and returning control of the 
request to the VxD. 
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